fix(@angular/ssr): allow using function with optional request context argument #28845
Conversation
pieh
force-pushed
the
fix/ssr-allow-optional-request-context-argument
branch
from
1c4246e to
b19a5e0
Compare
| @@ -16,6 +16,8 @@ | |||
| */ | |||
| export type RequestHandlerFunction = ( | |||
| request: Request, | |||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | |||
| ...ignoredArgs: any[] | |||
There was a problem hiding this comment.
Instead of using any here, can we instead use generics to infer the type?
Example
export type RequestHandlerFunction<T = unknown> = (
request: Request,
requestContext?: T,
) => Promise<Response | null> | null | Response;
export function createRequestHandler<T = unknown>(
handler: RequestHandlerFunction<T>,
): RequestHandlerFunction<T> {
}
|
I found alternative that doesn't require type modification - if anyone is interested it's something like this (attempted to simplify it in case other would face similar issue to solve): import { AsyncLocalStorage } from 'node:async_hooks'
import { AngularAppEngine, createRequestHandler } from '@angular/ssr'
import type { Context } from '@netlify/edge-functions'
const angularAppEngine = new AngularAppEngine()
const ContextStorage = new AsyncLocalStorage<Context>()
function requestHandlerImpl(request: Request) {
const context = ContextStorage.getStore()
// context will be undefined in dev, but should be defined in prod
return angularAppEngine.handle(request, context)
}
// this will be production deployment entry point - it sets context on the async local storage and we can access it later in common handler implementation without passing it as function argument
export default function prodHandler(request: Request, context: Context) {
return ContextStorage.run(context, () => requestHandlerImpl(request))
}
// dev
export const reqHandler = createRequestHandler(requestHandlerImpl)So I'll close this PR as given that there is pretty portable solution that can be adjusted to work with any provider - attempting to adjust the types for specific signature is unnecessary risk to take and would be annoying to deal with in the future if another incompatible signature would need to be handled. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Please check to confirm your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
When using
createRequestHandleron Netlify edge function compatible request handler function I am forced to use@ts-expect-errordirective currently:Issue Number: N/A
What is the new behavior?
Don't need to use
@ts-expect-errordirective anymore.Does this PR introduce a breaking change?
Other information
From what I understand applying metadata done by
createRequestHandleris used to recognize in dev mode that exported handle can be used to handle requests and falling back to "default" when it's not (and ignoring any customizations inserver.tsfile in dev mode because of it), so there doesn't seem to exist workaround the current type while still having access to second parameter?